Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
How to reproduce / test
When forwarding a message
handleAttachments
is callinggetRawAttachments
(viahandleForwardedAttachment
) for each attachment to forward.getRawAttachments
get the attachment id (which references a mime part of the original message) as argument.getRawAttachments
fetch the structure for the message.In a second query we request the actual body for the attachment (
buildAttachmentsPartsQuery
).getRawAttachments
for Attachment 1getRawAttachments
for Attachment 2getRawAttachments
for Attachment 3We see in the $attachments array that attachment 1 is at position 0, attachment 2 at 1 and attachment 3 at 2. The reason is that
$structure->partIterator()
always returns all parts of a message regardless if mail request the data for it or not.For example
getRawAttachments
for attachment 3 is also reading the data for attachment 1 and get an empty string because we do not request to fetch the data for it.mail/lib/Service/MailTransmission.php
Lines 549 to 550 in 1752cbb
In
handleForwardedAttachment
mail always uses the attachment at position 0 for the data. for attachment 3 we add the empty data for attachment 1.This patch changes the behavior to skip parts we did not request.